GermanWikipedia - /page/entry.mu

Micron Document

<!DOCTYPE html>

<title>Network Block Device</title>

</head>

<h1 id="firstHeading" class="firstHeading mw-first-heading"><span class="mw-page-title-main">Network Block Device</span></h1>

</header>

</div>

<div id="mw-content-text" class="mw-body-content mw-content-ltr" lang="de" dir="ltr"><div class="mw-content-ltr mw-parser-output" lang="de" dir="ltr"><p>Ein <b>Network Block Device</b> (<a href="Englische_Sprache" title="Englische Sprache">engl.</a> für <i>Netzwerk-Blockgerät</i>, abgekürzt <i>NBD</i>) ist eine Art <i>virtuelle <a href="Laufwerk_(Computer)" title="Laufwerk (Computer)">Festplatte</a></i>, auf die ein <a href="Computer" title="Computer">Rechner</a> via <a href="Internet_Protocol" title="Internet Protocol">Internetprotokoll</a> zugreifen kann. Das NBD wird von einem NBD-<a href="Server" title="Server">Server</a> bereitgestellt. Er bietet hierfür eine eigene Festplatte, <a href="Festplattenpartition" class="mw-redirect" title="Festplattenpartition">Festplattenpartition</a> oder eine <a href="Datei" title="Datei">Datei</a> als NBD bestimmten anderen Rechnern (<a href="Client" title="Client">Clients</a>) an. Ein anderer Rechner (oder auch der gleiche) kann sich über eine <a href="Transmission_Control_Protocol" title="Transmission Control Protocol">TCP</a>-Verbindung mit dem NBD-Server verbinden und anschließend das NBD wie eine eigene lokale Festplatte benutzen.

</p><p>Derzeit existiert nur für <a href="Linux" title="Linux">Linux</a> eine <i>vollständige</i> NBD-Implementierung. Linux spricht sämtliche <a href="Massenspeicher" title="Massenspeicher">Massenspeicher</a> als sogenannte <a href="Ger%C3%A4tedatei#Blockorientierte_Geräte" title="Gerätedatei">Blockgeräte</a> an. Wenn ein Linux-Rechner ein Network Block Device nutzen soll, muss <span style="font-family:monospace;"><i>NBD support</i></span> in der <a href="Linux_(Kernel)" title="Linux (Kernel)">Linux-Kernel</a>-Konfiguration aktiviert sein, bzw. das <a href="Kernel-Modul" title="Kernel-Modul">Kernel-Modul</a> <span style="font-family:monospace;">nbd.ko</span> geladen sein. Ein <a href="Userspace" class="mw-redirect" title="Userspace">Userspace</a>-<a href="Dienstprogramm" title="Dienstprogramm">Hilfsprogramm</a> namens <span style="font-family:monospace;">nbd-client</span> stellt nun die TCP-Verbindung zum NBD-Server her, gibt die bestehende Verbindung an den <a href="Kernel_(Betriebssystem)" title="Kernel (Betriebssystem)">Kernel</a> weiter und beendet sich dann. Dies hat den Vorteil, dass der Kernel sich nicht mit dem Verbindungsaufbau (und einer eventuellen <a href="Authentisierung" class="mw-redirect" title="Authentisierung">Authentisierung</a> usw.) befassen muss.

</p><p>Der NBD-Server ist betriebssystemunabhängig. Er kann also auch auf einem Nicht-Linux-System laufen, da keine Linux-spezifischen Funktionen benötigt werden. Es existiert ein Programm namens <span style="font-family:monospace;">nbd-server</span>, das nichts weiter tut, als eine gegebene Datei (oder Partition etc.) an einem angegebenen TCP-<a href="Port_(Netzwerkadresse)" title="Port (Netzwerkadresse)">Port</a> bereitzustellen.

</p><p>Prinzipiell ist es möglich, über NBD einen festplattenlosen Rechner zu betreiben, der als einzigen Massenspeicher ein NBD besitzt. Da jedoch zum Aufbau der Verbindung noch ein externes Programm (<span style="font-family:monospace;">nbd-client</span>) benötigt wird, ist dies nur mit Konzepten wie der <i>init-ramdisk</i> zu realisieren, einem <a href="Virtuelles_Dateisystem" title="Virtuelles Dateisystem">virtuellen Dateisystem</a>, welches im <a href="Random-Access_Memory" title="Random-Access Memory">RAM</a> gehalten wird und im Kernel selbst gespeichert ist, sodass es nach dem Booten zur Verfügung steht.

</p><p>Da die Originalversion von NBD einige Schwächen hat (z. B. die Begrenzung auf 4 <a href="Byte" title="Byte">Gigabyte</a> pro NBD), gibt es verschiedene Erweiterungen, die teilweise als „enhanced NBD“ bezeichnet werden. Diese sind jedoch <a href="Kompatibilit%C3%A4t_(Technik)" title="Kompatibilität (Technik)">inkompatibel</a> zum Original-NBD.

</p>

<div class="mw-heading mw-heading2"><h2 id="NBD-Protokoll_(ab_Version_2.6)"><span id="NBD-Protokoll_.28ab_Version_2.6.29"></span>NBD-Protokoll (ab Version 2.6)</h2></div>

<p>Das Protokoll ist ein Binärprotokoll. Sämtliche Mehrbytewerte werden dabei in <a href="Network_Byte_Order" class="mw-redirect" title="Network Byte Order">Network Byte Order</a> gesendet.

</p>

<div class="mw-heading mw-heading3"><h3 id="Handshake">Handshake</h3></div>

<p>Zuerst kommt eine Initialisierungsphase, bei der Daten zwischen dem NBD-Server und dem NBD-Clientprogramm ausgetauscht werden. Dieses Protokoll ist <i>unabhängig</i> vom NBD-Treiber im Linux-Kernel und variiert bei verschiedenen NBD-Implementierungen.

</p>

<div class="mw-heading mw-heading4"><h4 id="Version_≤2.9.16"><span id="Version_.E2.89.A42.9.16"></span>Version ≤2.9.16</h4></div>

<p>Das alte Handshake-Protokoll unterstützt genau ein Block Device pro Port.

Sobald ein Client sich zum NBD-Server verbunden hat, sendet der Server folgende <a href="Datenstruktur" title="Datenstruktur">Datenstruktur</a>:

</p>

<caption>NBD Initialization packet (Server→Client)<sup id="cite_ref-1" class="reference"><a href="#cite_note-1"><span class="cite-bracket">[</span>1<span class="cite-bracket">]</span></a></sup>

</caption>

<th>Offset</th>

<th>Datentyp</th>

<th>Beschreibung

</th></tr>

<tr>

<td>INIT_PASSWD</td>

<td>Identifizierungsstring <code>{'N', 'B', 'D', 'M', 'A', 'G', 'I', 'C'}</code>

</td></tr>

<tr>

<td>cliserv_magic</td>

<td><a href="Magische_Zahl_(Informatik)" title="Magische Zahl (Informatik)">Magic Number</a> 0x00420281861253

</td></tr>

<tr>

<td>export_size</td>

<td>Größe des exportierten Blockdevices (in Byte)

</td></tr>

<td>flags</td>

<td>Flags:

<ul><li>Bit 0: Es sind Flags vorhanden</li>

<li>Bit 1: Gerät ist read-only</li>

<li>Bit 2: Gerät unterstützt „FLUSH“-Befehl zum Leeren von Schreibcaches</li>

<li>Bit 3 und 4: <i>ungenutzt</i></li>

<li>Bit 5: Gerät unterstützt den TRIM-Befehl, mit dem das Dateisystem dem Blocklayer freigewordene mitteilen kann</li></ul>

</td></tr>

<tr>

<td>reserved</td>

<td>Reserviert (Derzeit gefüllt mit Nullbytes)

</td></tr></tbody></table>

<p>Akzeptiert der Client den Identifizierungsstring oder die Magic Number nicht, schließt er die Verbindung. Andernfalls gilt die Verbindung als erfolgreich aufgebaut.

</p>

<div class="mw-heading mw-heading4"><h4 id="Version_≥_2.9.17"><span id="Version_.E2.89.A5_2.9.17"></span>Version ≥ 2.9.17</h4></div>

<p>Das neue Handshake-Protokoll benutzt den IANA-registrierten Port 10809 und ein anderes Nachrichtenformat, das dem Server erlaubt, über einen TCP-Port mehrere Blockgeräte anzubieten, aus denen der Client über ihren Namen eines auswählen kann. Zusätzlich wurden die 32 Bit <i>flags</i> in 2 16-Bit-Teile aufgespalten, die es erlauben, serverglobale und geräteabhängige Flags zu trennen.

</p>

<caption>Server Init packet (Server→Client)<sup id="cite_ref-2" class="reference"><a href="#cite_note-2"><span class="cite-bracket">[</span>2<span class="cite-bracket">]</span></a></sup>

</caption>

<th>Offset</th>

<th>Datentyp</th>

<th>Beschreibung

</th></tr>

<tr>

<td>INIT_PASSWD</td>

<td>Identifizierungsstring <code>{'N', 'B', 'D', 'M', 'A', 'G', 'I', 'C'}</code>

</td></tr>

<tr>

<td>cliserv_magic</td>

<td><a href="Magische_Zahl_(Informatik)" title="Magische Zahl (Informatik)">Magic Number</a> 0x49484156454F5054 (=„IHAVEOPT“)

</td></tr>

<tr>

<td>server_flags</td>

<td>Flags, die für den gesamten Server gelten. Üblicherweise haben die Flags den Wert 0003<sub>hex</sub>. Die Bits bedeuten im Einzelnen:<br>

<dl>

<dt>Bit 0</dt><dd>NBD_FLAG_FIXED_NEW_STILE: Gesetztes Bit zeigt an, dass ein bestimmter Handshake-Bug im Server gefixt ist</dd>

<dt>Bit 1</dt><dd>NBD_FLAG_NO_ZEROES: Gesetztes Bit zeigt an, dass die Headernachricht <i>nicht</i> mit 124 Nullbytes aufgefüllt wird</dd>

</dl>

</td></tr></tbody></table>

<p>Der Client antwortet mit seinen Flags. Da bisher keine Flags definiert sind, bestehen sie nur aus 32 Nullbits:

</p>

<caption>Client Init packet (Server→Client)

</caption>

<th>Offset</th>

<th>Datentyp</th>

<th>Beschreibung

</th></tr>

<tr>

<td>client_flags</td>

<td>bisher gleiche Bedeutung wie server_flags, also ebenfalls üblicherweise 0000'0003<sub>hex</sub>.

</td></tr></tbody></table>

<p>Anschließend sendet der Client verschiedene Optionen, die der Server entsprechend akzeptierend oder ablehnend quittiert:

</p>

<caption>Option packet (Client→Server)

</caption>

<th>Offset</th>

<th>Datentyp</th>

<th>Beschreibung

</th></tr>

<tr>

<td>cliserv_magic</td>

<td><a href="Magische_Zahl_(Informatik)" title="Magische Zahl (Informatik)">Magic Number</a> 0x49484156454F5054 (=„IHAVEOPT“)

</td></tr>

<tr>

<td>option_number</td>

<td>Kennnummer/Typ der Option

</td></tr>

<tr>

<td>option_length</td>

<td>Länge der Option (in Bytes)

</td></tr>

<tr>

<td><i>variabel</i></td>

<td>option_data</td>

<td>Daten der Option (abhängig vom Optionstyp)

</td></tr></tbody></table>

<p>Bisher sind 3 Optionen definiert:

</p>

<caption>NBD Optionen

</caption>

<th>Bedeutung

</th></tr>

<tr>

<td>NBD_OPT_EXPORT_NAME</td>

<td>Client wählt Namen des Blockgerätes: der Name folgt im <code>option_data</code>-Feld. Diese Option beendet automatisch die Optionsliste. Der Server schickt den geräteabhängigen Teil der Initialisierung (siehe unten).

</td></tr>

<tr>

<td>NBD_OPT_ABORT</td>

<td>Client möchte die Verbindung beenden

</td></tr>

<tr>

<td>Client möchte eine Liste mit den Namen der exportierten Blockgeräte

</td></tr></tbody></table>

<p>Der Server antwortet auf ein Option Paket mit einem Reply-Paket:

</p>

<caption>Reply packet (Server→Client)

</caption>

<th>Offset</th>

<th>Datentyp</th>

<th>Beschreibung

</th></tr>

<tr>

<td>reply_magic</td>

<td><a href="Magische_Zahl_(Informatik)" title="Magische Zahl (Informatik)">Magic Number</a> 0x0003e889045565a9

</td></tr>

<tr>

<td>option_number</td>

<td>Kennnummer/Typ der Option, die beantwortet wird<sup id="cite_ref-bug1_3-0" class="reference"><a href="#cite_note-bug1-3"><span class="cite-bracket">[</span>3<span class="cite-bracket">]</span></a></sup>

</td></tr>

<tr>

<td>reply_type</td>

<td>Typ der Antwort

</td></tr>

<tr>

<td>reply_length</td>

<td>Länge der Antwortdaten

</td></tr>

<tr>

<td><i>variabel</i></td>

<td>reply_data</td>

<td>Antwortdaten, sofern reply_length > 0

</td></tr></tbody></table>

<p>Folgende Antworttypen sind bisher definiert:

</p>

<caption>Reply types

</caption>

<th>Bedeutung

</th></tr>

<tr>

<td>Der Server akzeptiert die Option oder hat keine weiteren Antwortdaten (bei NBD_OPT_LIST)

</td></tr>

<tr>

<td>NBD_REP_SERVER</td>

<td>Beschreibung des Blockgerätes. Es folgt die Länge des Namens als 32-Bit-Nummer, der Name, und – falls noch Platz im Antwortpaket ist – evtl. weitere beschreibende Details als Klartext.

</td></tr>

<tr>

<td>NBD_REP_ERR_UNSUP</td>

<td>Client hat eine unbekannte Option geschickt

</td></tr>

<tr>

<td>NBD_REP_ERR_POLICY</td>

<td>Der Server hat die Option verstanden, aber dem Server ist nicht erlaubt, die Option anzunehmen (z. B. NBD_OPT_LIST kann in der Konfigurationsdatei erlaubt oder verboten werden)

</td></tr>

<tr>

<td>NBD_REP_ERR_INVALID</td>

<td>Der Server hat die Option verstanden, doch sie war syntaktisch ungültig

</td></tr>

<tr>

<td>NBD_REP_ERR_PLATFORM</td>

<td>Die Option wird von der Plattform, auf der der Server läuft, nicht unterstützt. (derzeit ungenutzt)

</td></tr></tbody></table>

<p>Die Aushandelsphase ist abgeschlossen, sobald der Server die NBD_OPT_EXPORT_NAME-Option positiv quittiert hat. Er schickt daraufhin die Kenndaten des exportierten Blockgerätes an den Client:

</p>

<caption>Device Init packet (Server→Client)

</caption>

<th>Offset</th>

<th>Datentyp</th>

<th>Beschreibung

</th></tr>

<tr>

<td>device_size</td>

<td>Größe des exportierten Blockgerätes (in Byte)

</td></tr>

<td>device_flags</td>

<td>Flags, die für das exportierte Gerät gelten:

<ul><li>Bit 0: Es existieren Flags</li>

<li>Bit 1: Gerät ist read-only</li>

<li>Bit 2: Server & Gerät unterstützen das NBD_CMD_FLUSH-Kommando</li>

<li>Bit 3: Server & Gerät unterstützen das NBD_CMD_FLAG_FUA-Flag</li>

<li>Bit 4: NBD_FLAG_ROTATIONAL: exportierte Daten liegen auf einem rotierenden Medium (klassische Festplatte), was der Client bei dem Zugriffsmuster auf die Blöcke berücksichtigen kann</li>

<li>Bit 5: Server & Gerät unterstützen das NBD_FLAG_SEND_TRIM-Kommand</li></ul>

</td></tr>

<tr>

<td>padding</td>

<td><i>ungenutzt, alle 0</i>

</td></tr></tbody></table>

<div class="mw-heading mw-heading3"><h3 id="Datenphase">Datenphase</h3></div>

<p>Der NBD-Client leitet die Informationen über die Größe des Blockdevices, eventuelle Flags und den geöffneten <a href="Socket_(Software)" class="mw-redirect" title="Socket (Software)">Socket</a> über spezielle Systemaufrufe an den Kernel weiter und beendet sich. Der Kernel übernimmt dann die weitere Kommunikation über diesen Socket.

</p><p>Der Kernel auf Clientseite stellt nun Lese- und Schreibanfragen (Requests) an den Server. Diese haben folgenden Paketaufbau:

</p>

<caption>NBD Request (Client→Server)<sup id="cite_ref-nbd.h_4-0" class="reference"><a href="#cite_note-nbd.h-4"><span class="cite-bracket">[</span>4<span class="cite-bracket">]</span></a></sup>

</caption>

<th>Offset</th>

<th>Datentyp</th>

<th>Beschreibung

</th></tr>

<tr>

<td>magic</td>

<td><a href="Magische_Zahl_(Informatik)" title="Magische Zahl (Informatik)">Magic Number</a> 0x25609513

</td></tr>

<tr>

<td>0: Lesezugriff; 1: Schreibzugriff; 2: kontrolliertes Verbindungsende; 3: Flush cache; 4: <a href="TRIM" class="mw-redirect" title="TRIM">TRIM</a>-Kommando

</td></tr>

<tr>

<td>handle</td>

<td>8 Bytes, die im Reply identisch mitgeschickt werden, um dieses einem Request zuordnen zu können

</td></tr>

<tr>

<td>Offset (in Bytes), ab dem gelesen/geschrieben werden soll

</td></tr>

<tr>

<td>Länge des Datenblocks

</td></tr></tbody></table>

<p>Bei Schreibzugriffen folgen unmittelbar darauf die zu schreibenden Daten. Der Server beantwortet jeden Request mit einer Antwort (Reply). Diese hat folgenden Aufbau:

</p>

<caption>NBD Reply (Server→Client)<sup id="cite_ref-nbd.h_4-1" class="reference"><a href="#cite_note-nbd.h-4"><span class="cite-bracket">[</span>4<span class="cite-bracket">]</span></a></sup>

</caption>

<th>Offset</th>

<th>Datentyp</th>

<th>Beschreibung

</th></tr>

<tr>

<td>magic</td>

<td>Magic Number 0x67446698

</td></tr>

<tr>

<td>error</td>

<td>0=OK (kein Fehler aufgetreten)

</td></tr>

<tr>

<td>handle</td>

<td>Kopie des Handles im zugehörigen Request

</td></tr></tbody></table>

<p>Bei Antworten auf Lese-Requests folgen unmittelbar darauf die angeforderten Daten.

</p>

<div class="mw-heading mw-heading2"><h2 id="Siehe_auch">Siehe auch</h2></div>

<ul><li><a href="Loop_device" title="Loop device">Loop device</a>: Die gleiche Idee mit einem lokalen Gerät</li>

<li><a href="ISCSI" title="ISCSI">iSCSI</a>: Ein konkurrierendes System</li>

<li><a href="Network_File_System" title="Network File System">Network File System</a>: Agiert auf einer anderen Ebene, hat dafür aber auch einen weitaus größeren Bekanntheitsgrad</li></ul>

<div class="mw-heading mw-heading2"><h2 id="Weblinks">Weblinks</h2></div>

<ul><li><a rel="nofollow" class="external text" href="https://nbd.sourceforge.io/">NBD-Website</a></li></ul>

<div class="mw-heading mw-heading2"><h2 id="Einzelnachweise">Einzelnachweise</h2></div>

<li id="cite_note-1"><span class="mw-cite-backlink"><a href="#cite_ref-1">↑</a></span> <span class="reference-text">Aus dem Quellcode von nbd-2.9.13/cliserv.h</span>

</li>

<li id="cite_note-2"><span class="mw-cite-backlink"><a href="#cite_ref-2">↑</a></span> <span class="reference-text">Aus dem Quellcode von nbd-3.2/proto.txt</span>

</li>

<li id="cite_note-bug1-3"><span class="mw-cite-backlink"><a href="#cite_ref-bug1_3-0">↑</a></span> <span class="reference-text">Wird entgegen der Protokoll-Beschreibung in Host-Byteorder gesendet. Wert vom Client beim Einlesen ignoriert.</span>

</li>

<li id="cite_note-nbd.h-4"><span class="mw-cite-backlink">↑ <sup><a href="#cite_ref-nbd.h_4-0">a</a></sup> <sup><a href="#cite_ref-nbd.h_4-1">b</a></sup></span> <span class="reference-text">Aus dem Header /usr/include/linux/nbd.h</span>

</li>

</ol></div><div><div class="zim-footer">

Dieser Artikel wurde von <a class="external text" title="Zuletzt bearbeitet am 2024-10-23" href="https://de.wikipedia.org/wiki/?title=Network_Block_Device&oldid=249686553">Wikipedia</a> herausgegeben. Der Text ist unter <a class="external text" href="https://creativecommons.org/licenses/by-sa/4.0/deed.de">Creative Commons Attribution-Share Alike 4.0</a> verfügbar, sofern nicht anders angegeben. Für die Mediendateien können zusätzliche Bedingungen gelten.

</div>

</div></div>

</div>

</main>

</div>

</body></html>